Improvement: safeguards for automatic releases, the review queue and community expectations - #897

These are the safeguards we picked after the "Die Open Source Community bricht zusammen" video (The Morpheus, May 2026): xz-style trust capture, AI-cheap contributions, one maintainer carrying the review load, and hostile users.

What was wrong or hard:

• A registered author's update (or a stolen author account) could auto-publish any code inside its own module folder. Followers were told right away, and the owner learned of it only from GitHub's general notifications.
• Red pull requests sat in the owner's review list, and the template had 18 checkboxes an agent ticks in a second, most of them for things CI already enforces.
• Nothing told players that module authors owe no fix or reply time, or how moderation escalates.

What this changes:

1. Auto-release guard (scripts/author-update-git.mjs)
   • An author update whose source names a 32-bit address (0x + 8 hex digits) that the published version never named goes to owner review. The bot posts the reason on the PR once.
   • Replayed over the last 250 merged PRs: 10 of 44 module updates would have gone to owner review, all of them feature updates adding hooks or stock calls (for example Apply Scene +21 and Play Modes 0.2.0 +10). Bug fixes and tuning stay automatic.
   • It's a tripwire, not a sandbox: an address computed at run time passes.
2. Owner notice. After every automatic merge the bot comments on the PR with an @mention of the owner and a compare link.
3. 48-hour follower hold
   • verify-merge-approval.mjs hands the bot-merged modules to the build, and module-releases.json marks them authorRelease.
   • Migration 0082 adds module_releases.notify_after. The Worker stores the hold on first sight, and the hourly sync queues followers once it ends.
   • A newer version published during the hold replaces the held one, so followers only hear about the replacement. Owner releases stay immediate.
4. PR triage (scripts/pr-triage.mjs, hourly, reads API metadata only, no PR code)
   • A red PR gets the needs-work label and one comment, and loses the label when its checks go green.
   • It closes 14 days after labelling if there's no new commit.
   • A contributor without a published module gets one module PR reviewed at a time (one-at-a-time).
   • The owner's review list: is:pr is:open draft:false -label:needs-work -label:one-at-a-time.
5. PR template: 18 → 6 checkboxes. What CI enforces is one line about pr:ready. What stays is what no check can prove (guide read, rights and no firmware, real screenshots and hardware results), the author opt-in lines (unchanged, the workflow parses them) and one reviewer box.
6. Community expectations
   • The report forms (module, Digitakt/Digitone, configuration) and the forum's "Keep it kind" tip now say that authors owe no fix or reply time, linking to the rules.
   • Community rules (EN + DE) gain "What to expect from module authors" and the moderation steps: reminder, hidden content, temporary suspension, permanent suspension.
   • CODE_OF_CONDUCT.md covers GitHub.
   • Saved replies are in COMMUNITY_OPERATIONS.md.
7. Policy text: registered authors keep two-factor authentication on (a condition, since GitHub can't verify it), and release authority grows slowly and stays narrow.

How I checked it:

• New tests: address guard (new vs. known addresses, across files and letter case), author-release hold (held, still held after the flag disappears, released, replaced), triage policy. The related suites (170 tests) are green.
• PR_TRIAGE_DRY_RUN=1 against the live repository: only FM Synth 0.1.5: scale quantizer on MIDI tracks (the author's 2.13 quantizer) #555 and Tuner 0.1.0-experimental (new module) #560 would get needs-work on the first run. Nothing is queued or closed.
• npm run pr:ready: typecheck, lint, bundle, the app tests and every catalogue check pass. The only failure is test_runtime_loader.test_published_module_packages_rebuild_byte_for_byte (the Play Modes standalone recipe, Play Modes 0.2.0 has no USB package: USB installs still get 0.1.1 #764). It needs local firmware, CI skips it, and it fails the same way locally on main.
• Merged main after Docs: ask a module's author before changing their module #896 ("ask the author first"): its "author said yes" box is now the first item under "No check can prove these".

Owner decisions before merge:

• The community rules text changed, but COMMUNITY_RULES_VERSION was not bumped. The page promises to explain material changes before they apply, so decide whether this counts as one, and whether to bump and announce it.
• Merging starts the hourly triage. FM Synth 0.1.5: scale quantizer on MIDI tracks (the author's 2.13 quantizer) #555 and Tuner 0.1.0-experimental (new module) #560 (timhastie) get needs-work on its first run and close after 14 days if they stay red.
• A second reviewer with merge rights for Fix:/Docs: PRs is not set up here; it needs a name from you.

Open gaps, not fixed here:

• Digitakt/Digitone .elemod files under vendor/elekloader/catalog/ are checked for their approved stock targets, but their code isn't proven to come from the reviewed source, and the address guard can't see inside them. The 48-hour hold and the owner notice still apply to them.
• A rare ordering can skip the hold: if the deploy notice for an author release fails and the next deploy is an owner commit before the hourly sync runs, followers are told right away.

What the guides lacked or got wrong, and where I fixed it: the author-update guide didn't say what stops a hijacked author account. That's now in MODULE_AUTHOR_UPDATES.md; triage is under Make it mergeable.

🤖 Generated with Claude Code